System and Method for Problem List Reconciliation with Care Plan Generation in an Electronic Medical Record

ABSTRACT

A method for generating orders for a care plan through a problem list in an electronic medical record or an electronic health record includes the steps of mapping, using a computer, entries in a problem list with a respective concept in an interface terminology, analyzing, by a computer, each mapped entry to determine related problem list entries, grouping related entries into one or more categories, and aggregating a plurality of care plans relevant to one of the categories. Care plans may include medications and labs, and each care plan entry also may be coded with an external terminology, such as RxNorm or LOINC.

This application is a continuation of U.S. application Ser. No.14/530,727, filed Nov. 1, 2014, which claims priority to U.S.provisional application 61/943,109, filed Feb. 21, 2014, which isincorporated herein by reference.

BACKGROUND OF THE INVENTION

Patient electronic medical records (EMRs) are used to store a patient'smedical history in one location. EMRs permit more completerecordkeeping, which may lead to improved patient care, as healthcareprofessionals may be able to quickly and thoroughly review the patient'sprevious and current medical conditions in one location. EMRs also mayfacilitate portability of healthcare records.

As computer use has become more prevalent, electronic health records orelectronic medical records (EHRs or EMRs) have become the industrystandard for documenting patient care. Industry initiatives andgovernment legislation have facilitated EHR implementation and use. Mostnotable among them is the Health Information Technology for Economic andClinical Health Act (HIT ECH), which gives incentives to providerstoward implementation and demonstration of meaningful EHR use.

An aspect of reliable and accurate information is ensuring thatproviders have the ability to capture their clinical intentionsregarding patient care through terminologies. Healthcare terminology haslong been called “the language of medicine,” but, in the electronic age,this language has to be readable by both humans and computers. Variousterminologies are used in defining associated terms.

Terminology

Terminology is a set of descriptions used to represent concepts specificto a particular discipline. It also is the foundation of EHR data. Forexample, the terms “heart attack” and “MI” describe the same concept ofmyocardial infarction. The concept in turn may be associated with codesthat are used for a variety of purposes.

Different healthcare terminologies may have their own unique featuresand purposes. For example, one set of terminologies, RxNorm, encodesmedications, while another set of terminologies, e.g., LogicalObservation Identifiers Names and Codes (referred to under the trademark“LOINC”), is used for laboratory results.

Terms related to terminology include: Administrative code sets; Clinicalcode sets; and Reference terminologies.

Administrative code sets may be designed to support administrativefunctions of healthcare, such as reimbursement and other secondary dataaggregation. Common examples are the International Classification ofDisease (ICD) and the Current Procedural Terminology, which is referredto via the trademark CPT. Each system may be different, e.g., ICD'spurpose is to aggregate, group, and classify conditions, whereas CPT isused for reporting medical services and procedures.

Clinical code sets have been developed to encode specific clinicalentities involved in clinical work flow, such as LOINC and RxNorm.Clinical code sets have been developed to allow for meaningfulelectronic exchange and aggregation of clinical data for better patientcare. For example, sending a laboratory test result using LOINCfacilitates the receiving facility's ability to understand the resultsent and make appropriate treatment choices based upon the laboratoryresult.

A reference terminology may be considered a “concept-based, controlledmedical terminology.” The Systematized Nomenclature of Medicine ClinicalTerms (referred to under the trademark “SNOMED CT”) is an example ofthis kind of terminology. It maintains a common reference point in thehealthcare industry. Reference terminologies also identify relationshipsbetween their concepts. Relationships can be hierarchically defined,such as a parent/child relationship. The reference terminology containsconcept A and concept B, with a defined relationship of B as a child ofA. SNOMED CT includes concepts such as heart disease and heart valvedisorder, and their defined relationship identifies heart valve disorderas a child of heart disease.

Reference terminology may allow healthcare systems to get value fromclinical data coded at the point of care. In general, reference termsmay be useful for decision support and aggregate reporting and may bemore general than the highly detailed descriptions of actual patientconditions. For example, one patient may have severe calcific aorticstenosis and another might have mild aortic insufficiency; however, ahealthcare enterprise might be interested in finding all patients withaortic valve disease. The reference terminology creates links between“medical concepts” that allow these types of data queries.

One method of managing these various terminologies may involvegenerating an interface terminology configured to capture each user'sclinical intent. The reference terminology may include a plurality ofdomains (problem, plan, medication, etc.), a plurality of uniqueconcepts within each domain, and one or more descriptions mapped to eachconcept, where each description represents an alternative way to expressa concept, and where each description captures various users' clinicalintent. Exemplary methods for managing multiple terminologies throughthe use of an interface terminology may be found in the commonly ownedU.S. patent application Ser. No. 13/660,512, the contents of which areincorporated herein by reference.

While EHRs aggregate patient information into a single location, theymay suffer from information overload. For example, an EHR may include apatient problem list. Every time the patient indicates that he or shehas a problem, that problem may get added to the patient list, causingthe list to grow. Other types of additions include automated additionsor additions to the problem list from multiple caregivers given accessto modify the same list. Over time, this list may contain many entries,including duplicate problems, inaccurate problems, and outdated orresolved problems.

Similarly, because the problem list includes all of the patient's statedproblems, it may contain information that, while current and unique, maynot be that useful to the practitioner, particularly when thepractitioner is a specialist. At the same time, the problems thatactually are most useful to the practitioner may be overlooked orotherwise missed when the practitioner is reviewing the entire problemlist.

In addition, while one of the benefits of an EMR is record portability,difficulties may arise when problem lists from multiple sources arecombined, particularly if those lists come from different types orformats of EMRs, or contain problems that are represented withinmultiple different reference vocabularies.

What are needed are a system and method that address one or more of theissues presented above in order to present a clearer picture of thepatient's problems.

BRIEF SUMMARY OF THE INVENTION

In one aspect, a method for generating orders for a care plan through aproblem list in an electronic medical record or an electronic healthrecord includes the steps of mapping, using a computer, entries in aproblem list with a respective concept in an interface terminology,analyzing, by a computer, each mapped entry to determine related problemlist entries, grouping related entries into one or more categories, andaggregating a plurality of care plans relevant to one of the categories.

In another aspect, a method for generating orders for a care planthrough a problem list in an electronic medical record or an electronichealth record includes the steps of mapping, using a computer, entriesin a problem list with a respective concept in an interface terminology,analyzing, by a computer, each mapped entry to determine related problemlist entries, grouping related problem list entries into one or morecategories, mapping, using a computer, a plurality of care plans to atleast one respective concept in the interface terminology, and linkingcare plans to problem list entries via matching interface terminologyconcepts. The method also may include aggregating all care plans linkedto problem list entries that are grouped into one of the categories.Additionally, upon selection of a problem list entry, the method mayinclude displaying all care plans aggregated for the category to whichthe problem list entry is grouped.

In either aspect, the care plans may include one or more medications,which may encoded with an RxNorm code. Additionally or alternatively,the care plans may include one or more laboratory tests, which may beencoded with a Logical Observation Identifiers Names and Codes (LOINC)code.

Problem list elements already may be tagged or coded with one or moreterminologies, including administrative, clinical, and referenceterminologies. The method may include determining a mapping betweenthese terminologies and interface terminology concepts in order todetermine which interface terminology concepts apply.

Features and advantages are described in the following description, withreference to the accompanying drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a depiction of a method of reconciling a general problem listinto one or more clinical categories based on concept groupings. In thiscase the concept group is related to clinical specialties such asGastroenterology or Cardiovascular. Many different concept groupings canbe enabled using the methods described.

FIG. 2 is a depiction of exemplary relationships between problem listelements within a clinical category and an example of how problems canbe nested together or seen in full detail.

FIG. 3 is a depiction of problem lists from different sources,illustrating differences in the way in which problem list elements arearranged and displayed.

FIG. 4 is a depiction of the reconciliation of elements of multipleproblem lists into a single, unified list.

FIG. 5 illustrates two separate problem lists side-by-side, the listsrequiring reconciliation, but the entries in the lists being seeminglyrather different from one another.

FIG. 6 illustrates the two lists mapped on top of one another, withduplicates highlighted in a first fashion and non-duplicates highlightedin a second fashion.

FIG. 7 is a depiction of a reconciled problem list created from the twolists in FIG. 5 using the methods described.

DETAILED DESCRIPTION

As seen in FIG. 1, a method for processing electronic medical recordproblem lists may be employed to generate a clinically relevant patientprofile. In one aspect, the patient profile may be useful to a clinicianbecause it may categorize and group related problems according toconcept groupings, and groupings may be determined based on semanticdistance between the represented concepts. For example, allcardiovascular problems may be grouped under a “cardiovascular”category, all kidney-related problems may be grouped under a “renal”category, etc.

In addition, the system may attach indicator flags to the problemswithin each category, which may permit later ranking and ranked displayof the problems according to attributes, such as severity, timeliness,or other concepts such as classification within a clinical measure. Oneexample of such a flag is seen in FIG. 2, in which the problem “Diabetesmellitus” and the related problems clustered underneath that summaryproblem are marked with a CQM flag. The system may apply an indicatorflag to the summary problem if any of its clustered problems (as thatterm is discussed in greater detail below) include the flag.

The CQM, i.e., Clinical Quality Measurement, flag indicates that itsassociated problem element must comply with CQM requirements fortreatment and documentation in order to be eligible for thereimbursements provided for such compliance. Thus, a problem having thisflag may be presented to the user as a higher value or higher priorityproblem element. In addition to having the flag callout, this flag alsomay be used as a factor in problem list ranking. For example, CQMproblems may be ranked and presented higher on the problem list withineach category than other, non-flagged problem elements.

Other potential flags may include HCC (Hierarchical Condition Category),CC (Complication and Comorbidity), and MCC (Major Complication andComorbidity). One of ordinary skill in the art would appreciate thatvalues associated with these terms are reflective of the severity oftheir underlying problems. As such, problems flagged with one or more ofthese flags may provide a visual indicator to the user that they mayneed to be addressed with higher priority than other problems on thelist.

Returning to FIG. 1, multiple criteria in addition to the indicatorflags may be applied to the problems in order to determine the rankingswithin these lists. For example, problems that are associatedwith/require medication may be ranked higher than those that are/do not.Problems that are entered by a physician/clinician may be ranked higherthan those that are sourced from other entities later in the recordreview process, e.g., by a coder or other administrative personnel.Problems that are obtained from workflow or some other outsider source,e.g., those problems that may be extracted from review of the patient'schart may rank somewhere in between clinician- and coder-generatedproblems (assuming all other factors are the same). Problem entries maybe time-stamped, such that more recent problems may be ranked higherthan older problems.

The clinicians viewing the problem list then can see the problems thatpertain to their specialty quickly and easily, e.g., a cardiologist canlook for the cardiovascular category and then focus on its entries. Inone aspect, the clinician may be able to set up a filter to displaypreferred problems or categories of problems, while excludingnon-selected problems or categories from being displayed. In anotheraspect, clinicians may pre-establish a profile that includes detailsabout their preferred practice area(s). Upon logging-on to the system,the clinician's personal information may be retrieved. When theclinician selects a patient's record, the system then may cross-checkthe clinician's profile with each of the categories of problems. Thesystem then may display one or more problems or categories of problemsthat match that clinician's profile. In either case, the filter mayfunction to bring a specialty-based problem view to the front of theclinician's review.

Other filters may include the option to show an expanded list that showsevery problem in a category vs. a summary or nested list that shows thehighest level problem for a group of problems within a category, withthe other problems being closed off or otherwise hidden from view.

The system also enables identification of potentially sensitiveproblems, so that the EHR can mark them for special treatment such as asecondary layer of privacy for viewing, or special attention by theclinician who has access to the Problem List. Examples of “sensitive”problems include, e.g., HIV and mental illness. Marking a problem assensitive may allow it to be masked from some users, thereby restrictingaccess only to those who are authorized.

The system also may generate lists in order to call attention toproblems that may require more immediate attention or problems that mayaffect multiple disciplines. For example, another possible category maybe an “in focus now” category, which may display those problemscurrently most relevant to the user, regardless of whether the problemalso can fit into one of the other categories described above, and a“special display” category, which may list high priority problems ofextreme, immediate importance, or of problems which are always part ofthe patient's overall baseline health state. These problems may becategorized more specifically, but they may have effects that crossdisciplines, such that the clinician may desire to know about them whenaddressing the specific problems within his or her discipline.

In another aspect, it may be desirable to refine the problem list byeliminating redundancies or categorizing which problems are resolved vs.which ones are chronic or ongoing, etc. The same or similar rankingcriteria as those described above with regard to problem entries withineach category may be applied to the problem list as a whole in order torank the entries, regardless of categorization. Alternatively, thecategory that may apply to a particular problem also may serve as acriterion in this ranking analysis, e.g., a cardiac or neurologicalproblem may be ranked higher than an orthopedic one.

The system may display or output each tagged problem using descriptionelements within the interface terminology, i.e., alternative ways toexpress the concept, because this may better express clinical intent,particularly the intent of the entity that created the problem/added theproblem to the patient's list.

The system also may include a map between the various concepts withinthe interface terminology and with elements of other, externalterminologies and vocabulary datasets, such as ICD9, ICD10, SNOMEDCT,MeSH, and Clinical Quality Measure elements, etc. These mappings may beprecompiled such that the system may avoid needing to remaprelationships between interface terminology elements and the externalsets when dealing with additional problem lists, e.g., the lists ofother patients.

This mapping may serve as the basis for the categorization, grouping,rolling up, nesting, etc., of the entries in a problem list. Certaininterface terminology concepts may be related to other interfaceterminology concepts based on similar subject matter. For example, theremay be a plurality of concepts that pertain to cardiac conditions. Thus,all problems that map to these concepts may be grouped together forcategorization and display such as that shown in FIG. 1.

In addition to the ranking or sorting criteria describe above, theseoutside vocabulary mappings may be an additional factor used to rank theproblem list entries. For example, mappings to some establishedterminologies or vocabularies may be used to perform themapping/grouping described in the previous paragraph, and mappings to asecond terminology or vocabulary or a proprietary mechanism may be usedto sort more specifically within the determined categories.

Turning now to FIG. 2, it will be seen that certain problems not onlyfall within the same category as other problems but that they also maybe considered subsets of another problem, i.e., they may be clusterswithin that problem. These relationships can be determined and managedby using the interface terminology, which also may recognize thatcertain concepts are more general than others and thus arehierarchically related to those other concepts. The system may groupthese more specific concepts underneath the more general, parentconcept, thereby further arranging the problem list, whose entries maybe mapped to these sub-concepts. As it relates to presentation of theseproblem list entries, the system may display in the problem list theproblem that maps to the more general, parent concept and an indicatorthat other problem entries are nested or clustered and may be viewableunder that parent problem, e.g., by clicking on the indicator.

In one aspect, clustered problem elements underneath a more general,parent concept may be ranked or organized using one or more of thecriteria discussed above for ranking elements within the problem listgenerally. Alternatively, as seen in FIG. 2, clustered problem elementsmay be arranged using a more simplistic algorithm, e.g., they may bearranged alphabetically. In still another aspect, the system may rankflagged problems above non-ranked problems and then apply the moresimplistic algorithm within each of those subsets. In any event, thesystem may allow user customization, permitting the user to rearrangethe ordering of elements both in the problem list and within theclustered subsets, as discussed below.

From a database management perspective, clustered problems may be storedas a list of elements in a flat file database, with each elementpointing to its parent problem element. Alternatively, clusters may besub-trees in a hierarchical database structure underneath theirrespective category elements.

To this point, the patient list has been described as being patientspecific, i.e., each patient has his or her own list, with entriesspecific to that patient in order to accurately record the patient'sproblem history. The system and method may function similarly as a wayto bring a clearer clinical picture for a population aggregator, i.e.,determining what problems exist for a given population, or for a givenpatient who may have multiple problems culled from multiple sourceswithin a large data warehouse. In that case, the number of problems inthe aggregated list may be larger (likely significantly larger) than foran individual record within an EHR, although the methodology may remainthe same, i.e., each problem may be mapped to an interface terminologyconcept, concepts may be grouped and ordered, and the ordered problemsthen may be available for logical display and analysis.

As seen in FIG. 3, and as discussed above, another issue with problemlists may become evident when attempts are made to combine lists frommultiple different sources. These sources may format, store, and/orrepresent elements in the list differently from one another and not in aconsistent format.

In order to accomplish reconciliation of elements within a single list(i.e., grouping problems within a list into categories and establishingclusters within those categories, which may or may not include the stepof combining elements from multiple problem lists into a single list),the system may create an anchoring term from an interface terminologyfoundation technology that permits creation of a semantic distancebetween any two other terms from external vocabularies. This anchoringterm may be considered a central concept within an interfaceterminology. In one aspect, determining this anchoring term may beachieved by a concept tagging method, and examples of such a method maybe found in the commonly-owned co-pending U.S. application Ser. No.13/004,128, the contents of which also are incorporated by reference.

For example, the process may comprise populating a database with aplurality of distinct concepts, populating a database with a pluralityof descriptions, relating each description to a respective concept,reviewing the content (e.g., the problem list elements) for asatisfactory description match; and creating a tag for the satisfactorydescription match. Concepts may be well-defined clinical findings, i.e.,items that are distinct by nature. Descriptions may comprise a pluralityof words. Factors for determining whether the match is satisfactory mayinclude whether there is a textual match between a portion of thecontent and the description and a distance between words in the content,the words corresponding to discrete words of each description.

Each concept may be part of a tree or hierarchy of other concepts, i.e.,each concept preferably may have, at most, one parent concept, althoughit also may have multiple child concepts. A “Knee Pain” concept (term)may be expanded semantically to parent/child clinical concepts,including semantic distance that will help build the problem listranking. For example, knee pain may be connected up to the broaderconcept of joint pain, which may be connected to musculoskeletal pain.Similarly, knee pain may be connected down to the more specific conceptsof anterior knee pain and knee joint, painful on movement. This semanticdifference may be expressed in terms of discrete positive or negativevalues away from the concept.

The heuristic that determines a problem's final ranking may be afunction of description frequency and description presence factor, aswell as the semantic difference or distance from other descriptions.Because multiple descriptions may relate to a shared concept,description frequency may be a compound value of all occurrences of alldescription variances of a shared concept, here, e.g., the concept of“Knee Pain.” Relatedly, a term presence factor may reflect how “close”or “loose” a potential concept match may be. For example, the phrase“knee pain” may have a high term presence factor for the concept “kneepain,” whereas the phrase “pain under kneecap” may have a lower termpresence factor, reflecting the difference in terminology and inferencethat is required to make the match.

Thus, each problem list element is analyzed and tagged with adescription that represents the clinical intent behind that element, thedescription being part of an interface terminology and mapping withinthat terminology to a concept, thereby normalizing the problem listelements. The problems then may be analyzed, using those concept tags,to determine if any relationship exists among them, e.g., whether theyrepresent duplications or related concepts (broader than/lessthan/subset of), or whether they are unrelated. Once analyzed, theelements may be grouped and ranked as described above, for presentationto and review by the user.

Turning now to FIG. 4, the method may include incorporating andreconciling problem lists from multiple sources, e.g., from multiple EHRsources or from an EHR and from a Consolidated Clinical DocumentArchitecture (CCDA) source. This latter case may be particularly usefulin order to comply with Meaningful Use, Stage 2 (MU2) requirements,which require the ability to incorporate and reconcile an inbound CCDAproblem list with the home EHR list. In still another example, thesecondary list needing reconciliation may be generated by NaturalLanguage Processing (NLP) suggestions.

As with a single problem list, the final product may be an ordered,categorized, clinical problem list. In addition to this ordering,however, the system may determine and reconcile conflicts orredundancies between multiple lists. Reconciliation may require thesteps of: identifying which problems are identical; identifying whichproblems are closely related; and creating a mechanism to incorporate,preferably rapidly and accurately, reject, or refine both sets ofproblems into a new clinical set.

In this aspect, tools similar to those described above may be used toreconcile the multiple problem lists. For example, problems in each listmay be tagged using a common interface terminology. Once thiscommonality has been established, the entries from the two lists may becombined into a single list using the interface terminology mappings asa guidebook.

One advantage of this type of reconciliation is that one of the twolists already may include mappings between the problems and some kind ofcode set. For example, the CCDA-structured problem list that complieswith MU2 may have its problems coded with SNOMED-CT codes. As such, theanalysis of the problems in that list may be simplified, because it maybe easier to map the SNOMED-CT codes to interface terminology conceptsthan to do a mapping between the text of the problem and the interfaceterminology.

In addition, while this automated procedure may be able to reconcileproblem lists with a high degree of accuracy and completeness (e.g.,between about 90% and about 95%), the system may benefit from a humaninteraction component. As such, the system may include a package ofrefinement tools that may permit a user, e.g., a clinician that has theexperience and knowledge, to evaluate potentially similar entries anddetermine what, if any, relationship might exist between those entries.For example, the user may be able to move an entry from one categoryinto another, from no category to an existing category, or from anexisting category into either a new category or into an undefined area.The user also may able to move the entry around within the category,e.g., moving it up or down to reflect a higher or lower priority,respectively, or determining that it belongs as a subentry of analready-existing problem.

FIG. 5 shows one example of two lists for reconciliation side-by-side,e.g., an EHR list and a CCDA list for import. FIG. 6 then shows apresentation layer implementing one example of the reconciliationstrategy. This presentation layer depicts the entries from the EHR asthe left-justified items and the CCDA entries as the right-justifieditems. In addition, the system analyzes the data sets to determinewhether, once the problems have been mapped to the interface terminologyconcepts, there are any duplicates. If so, the presentation layer mayalert the user to the existence of the duplicates, e.g., by locating theduplicate next to the problem it matches and by graying it out orotherwise indicating that it should remain in that location and not bemoved elsewhere.

In addition, the system may flag non-duplicates, e.g., with theindicator arrows shown in FIG. 6. As can be seen, the system alreadyautomatically may have determined that the non-duplicates belong incertain categories. In this case, the presentation layer may be used bythe user to move the non-duplicates, either within the categories inwhich they were placed or to a different category altogether.

Turning now to FIG. 7, a reconciled problem list is shown, with themultiple lists combined into a single, comprehensive problem list. Newentries may be shown in boldface or otherwise may be highlighted toalert the user to the additions. In addition, different term sets may beused on the problem list and may be presented to the user. In oneaspect, the system may display the problems using the interfaceterminology concept labels that were applied to the problem entries.However, the system may also give the user an option to display theterms as they appeared in the lists prior to reconciliation, as thoseterms may more accurately reflect the clinical intent of the individualthat generated the problem. In that case, the interface terminologymapping may remain in the background, such that the interfaceterminology terms may not be exposed to the end users.

The system may function as a separate widget or application accessibleby an EHR software package. Preferably, however, this problem listanalysis and reconciliation tool may be integrated into the EHR package.

In still another aspect, the system may recognize that certaincombinations of problems may trigger one or more care plans. Thus, thesystem may analyze the various problem list entries to determine whethercare plans are recommended and if so, which ones. This analysis may beperformed using the interface terminology concepts tagged to eachproblem list element, which may increase processing efficiency since acomparison between those existing concepts and the various care plansmay be precompiled and only may require, e.g., a simple table lookup,instead of requiring analysis and evaluation of non-normalized problemlist terms as entered.

In conjunction with the organized problem list, the system then mayoutput and display a care plan callout with indicators referring to theassociated problems. For example, each care plan that the systemrecognizes may be displayed/highlighted/etc. in a distinct color, andthe problems associated with a care plan similarly may be highlighted inthe same color.

Additionally, depending on the number of problems in the list, thesystem may determine that multiple care plans are implicated. Thus, thesystem may rank those care plans, e.g., according to severity,timeliness, or other factors. Factors used in the ranking may includeone or more of those discussed above for determining problem listrankings. In addition, the system may analyze the problems that triggereach care plan, using the rankings of those problems as a factor inranking the care plans.

While the foregoing written description enables one of ordinary skill tomake and use the same, those of ordinary skill also will understand andappreciate the existence of variations, combinations, and equivalents ofthe specific exemplary embodiments and methods disclosed herein. Theclaims should therefore not be limited by the above described embodimentand method but should be interpreted within the scope and spirit of theinvention as claimed.

What is claimed is:
 1. A method for generating orders for a care planthrough a problem list in an electronic medical record or an electronichealth record, comprising: mapping, using a computer, entries in aproblem list with a respective concept in an interface terminology;analyzing, by a computer, each mapped entry to determine related problemlist entries; grouping related entries into one or more categories; andaggregating a plurality of care plans relevant to one of the categories.2. The method of claim 1, wherein the plurality of care plans comprisesone or more medications.
 3. The method of claim 2, wherein eachmedication is encoded with an RxNorm code.
 4. The method of claim 1,wherein the plurality of care plans comprises one or more laboratorytests.
 5. The method of claim 4, wherein each laboratory test is encodedwith a Logical Observation Identifiers Names and Codes code.
 6. Themethod of claim 1, further comprising: ranking each of the plurality ofcare plans; and displaying a ranked list of the plurality of care plans.7. The method of claim 6, wherein the ranking is based on at least oneof: severity, timeliness, and alphabetical order.
 8. The method of claim1, wherein, prior to the aggregating step, each care plan is pre-mappedto a respective one or more problem list entries.
 9. The method of claim8, wherein the pre-mapping step involves mapping each care plan to arespective concept in the interface terminology and cross-checking thosemapped concepts with the interface terminology concepts to which theproblem list entries are mapped.
 10. The method of claim 1, wherein thegrouping step includes analyzing semantic distances between conceptsmapped to the problem list entries.
 11. The method of claim 10, wherein,based on the semantic distances, certain problem list entries areclustered as a subset within a parent entry.
 12. The method of claim 11,wherein clustered entries are stored as a list of elements in a flatfile database, with each element pointing to the parent entry.
 13. Themethod of claim 11, wherein clustered entries are stored as a tree in ahierarchical database structure underneath a respective parent entryelement.
 14. A method for generating orders for a care plan through aproblem list in an electronic medical record or an electronic healthrecord, comprising: mapping, using a computer, entries in a problem listwith a respective concept in an interface terminology; analyzing, by acomputer, each mapped entry to determine related problem list entries;grouping related problem list entries into one or more categories;mapping, using a computer, a plurality of care plans to at least onerespective concept in the interface terminology; and linking care plansto problem list entries via matching interface terminology concepts. 15.The method of claim 14, further comprising: aggregating all care planslinked to problem list entries that are grouped into one of thecategories.
 16. The method of claim 15, further comprising: uponselection of a problem list entry, displaying all care plans aggregatedfor the category to which the problem list entry is grouped.
 17. Themethod of claim 14, wherein the plurality of care plans comprises one ormore medications.
 18. The method of claim 17, wherein each medication isencoded with an RxNorm code.
 19. The method of claim 14, wherein theplurality of care plans comprises one or more laboratory tests.
 20. Themethod of claim 19, wherein each laboratory test is encoded with aLogical Observation Identifiers Names and Codes code.